redis持久化rdb与aof

RDB(Redis DataBase)

rdb最简单的描述就是内存快照,执行命令的时候把redis的数据copy成一份二进制数据

命令

  • save 阻塞redis 主线程
  • bgsave 执行过程不会阻塞redis主线程

通常使用的都是bgsave进行rdb操作,但是不阻塞只是在生成rdb文件的时候不阻塞

bgsave的流程

  • 执行bgsave命令 。
  • redis 主线程会fork 出 bgsave 子进程。
  • bgsave子进程 会读取redis 的内存数据,生成RDB 文件。

redis 主线程会把数据复制给bgsave子进程,这个过程中redis是阻塞的,完成数据复制后子进程和主线程指向的都是相同的内存空间的数据,子进程读取copy来的内存数据生成二进制文件,当阻塞的同时如果出现了写操作,并不会破坏这份内存快照

这里用到的是redis的写时复制技术(CopyOnWrite,缩写COW),具体实现就是在key被操作的时候先在当前内存中开辟一个新的空间,修改完毕后,原来的key指向新的内存地址

缺点:rdb文件在生成的时候,数据修改是不会复制到rdb中的,也就是生成消耗了几秒就会丢失几秒的数据

AOF

aof开启后,在redis执行命令完后,会把当前执行的命令压缩到aof文件中

aof三种策略
策略 何时写盘 优点 缺点
Aways 同步写入 基本不丢失,增加延迟 io 忙的情况下,会增加线程返回结果的延迟时间,断电的时候会丢失还来的急写入的命令
EverySecond 每秒写入 性能好,不会增加太大延迟 断电会丢失一秒的数据
No 操作系统写入 性能好,不会增加太大延迟 丢失数据多少,由操作系统写磁盘频率决定
aof重写

实际情况aof文件中会存在很多没用的数据,比如我修改了a字段10次,实际上前9次对我数据备份的恢复是没有意义的,因为实际产生效果的是第十次修改.

aof的重写全过程和rdb生成规则几乎一模一样,都是复制数据到内存然后进行写入

当然生成aof重写文件的时候执行的redis命令也会存储到原aof中,防止aof重写失败

RDB AOF混合

其实在reids 4 之后,redis 还提供了AOF 和RDB 混合使用的方式,就是在每次生成RDB之间增加AOF,这样AOF的文件也不会很大,同时也弥补了每次生成RDB之间会丢失数据的缺点。

混合持久化本质是通过 AOF 后台重写(bgrewriteaof 命令)完成的,不同的是当开启混合持久化时,fork 出的子进程先将当前全量数据以 RDB 方式写入新的 AOF 文件,然后再将 AOF 重写缓冲区(aof_rewrite_buf_blocks)的增量命令以 AOF 方式写入到文件,写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。

开启:混合持久化的配置参数为 aof-use-rdb-preamble,配置为 yes 时开启混合持久化,在 redis 4 刚引入时,默认是关闭混合持久化的,但是在 redis 5 中默认已经打开了。
关闭:使用 aof-use-rdb-preamble no 配置即可关闭混合持久化。

优点:结合 RDB 和 AOF 的优点, 更快的重写和恢复。
缺点:AOF 文件里面的 RDB 部分不再是 AOF 格式,可读性差。